|
 |
|
|
|
 
This Article Is Taken From The Game Programming MegaSite, A Definitive Resource For Game Developers!
|
Find out more about myself and computer game services provided by Baldwin Consulting.
(Given at the 1999 Game Developers Conference)
In order to examine the ten top things every producer should know about game design, we will examine the game development process. Through this examination, we will look for these important nuggets.
First, we need to answer some basic questions. What do we mean by game design, game designer and producer? How are these things the same and different.
The producer, game designer, lead programmer, and lead artist are separate jobs. There is much overlap, and many times one individual may be responsible for more than one of these jobs, yet it is important to remember and distinguish the differences.
The producer is responsible for the entire project, creative, technical and commercial. More than anything, this is accomplished through facilitation of the other team members work.
The designer is responsible for the creative control of the project, and how it generates the entertainment value. The game design should be the designer’s expression and plan of this vision.
The lead programmer is responsible for the technical aspects of the project (i.e. the code and how it accomplishes the designer’s design). The code design should be the lead programmers expression and plan of this implementation.
The lead artist is responsible for managing the large amount of art in most projects, and interpreting the designer’s vision into specific graphic and audio expressions. The art design should be the lead programmers expression and plan of this implementation.
In reality, the division varies from project to project and company to company. Ultimate goal of each is the same, but the method is different. Both should be involved from the project from the start. Schedules, resources, etc should be worked out as a team (and include the Lead Programmer and Artist as well).
The cycle is composed of separate but interrelated segments. There are alternate development models.
Design, scheduling and estimation must incorporate ALL components of the development cycle.
The waterfall model is a good example of how this iterative process is accomplished. Think of the painter and his brush, and how she must interact with the painting to paint.
This is where the basic ideas of the game are developed. Preliminary game, code and art design are developed.
The Producer is NOT the game designer (ok, there are some exceptions). While it is good to provide input to the designer, all design decisions must ultimately be the designer’s. One method of management can be the benevolent dictatorship. Many times actually with two dictators, the producer AND the designer.
This is the template from which the game designer evolves the game design. It incorporates all of the forces involved including such forces as marketing and technology.
This is the bread and butter of the game designer where 90% of the game design is created. All aspects of the game and the design must be fleshed out at this point.
Would the game you are designing today be successful 5 years ago for a black and white Macintosh? If you answer no, then we are not talking about game design but instead trying to show off a technology. Design and art is the master, technology is the servant.
It does not die once coding starts. No more than an outline for a novel survives it’s writing. Allow methods and techniques that support this growth and change.
While acknowledging the change to come, still the design needs to incorporate all to come, for the interaction of all the parts are needed to assess the whole. Not only should the story and elements be incorporate into the design, but also most important since a game is an interactive work, how the pieces interact must be carefully planned.
Although the design is the responsibility of the designer, the total project is the responsibility of the producer. Moreover, risk management is an important aspect of the total project. The design of the game directly influences the risk involved in development of a game. Tried and true is normally less risk both in design and in implementation. Nevertheless, new concepts and ideas many times offers the potential for a ‘better’ product. Understand the nature of the risk the designer hands your project and be willing to accept those risk.
Once you have a game design, you then need an architectural design. This is the design specifications for the ‘physical’ product, i.e. the code. The code in my first game was less than 100 lines. However, most games today have tens of thousands of lines. How this code will function, and how it will interact with itself requires as much planning as does the game.
The producer should both understand and support this difference. Game Design is creation of the creative expression. Code Design is creation of the framework that holds that creative expression.
This is what most people think about when they think of game development. Moreover, while a substantial and important part, it is still only a part of the game development process. Much of the game design is done by this point, but the iterative nature of game design strongly occurs during this phase.
Once you have a working product, it is time to examine it in light of the original goals for the project. Again, a difference between code design and game design is important to notice. Debugging involves correcting problems and mistakes in the code. Redesign involves correcting problems and mistakes in the game design. Both are important polishing processes.
Testing is that final process of polishing, where all the parts of the game, including the design are examined in detail for anything that might make the product better. Here is where the quality of the product is assured.
More is not better. There is always a strong desire to add more ‘features’ and more bells and whistles to a product. However, this must be done with care. Not only is there is the outside pressure to get the product on the shelves that suggest the product must be finished, but there is the original goal of the product. That of entertainment and value. At some point, new ‘features’ to the design or game can actually detract from that final goal. Be aware always of the effect of any addition to the total product.
Of all the ten things discussed, probably the most important item for the producer to understand is that game design is not about code. It is about how this ‘work’ (or even entertainment art) will entertain the consumer. It is about the interaction of the consumer with the game. It is about expression and emotion.
